fix(app-shell): the bell's Approvals and Activity tabs fill in off-app, from one shared fetch (#4197) - #4223

Fixes #4197

AppHeader gated two of the three streams that fill the bell on variant === 'app': the pending-approvals poll (if (!isApp || !user?.id) return;) and the sys_activity read (if (!dataSource || !isApp) return;). The bell renders on Home, Organizations and the full-page AI screen too, so off-app the Approvals tab read "No pending approvals" and the Activity tab "No recent activity" — on the very page whose own cards were listing both, from the same endpoint and the same object.

Since #4199 un-gated the inbox half, the badge (unreadTopics + pendingApprovalsCount) fetched only its first addend off-app: one user with one set of data read 1 on Home and 3 inside an app, and the popover's own breakdown line disagreed with the number on the bell.

Consumer map

Which surfaces read these two feeds, and what each fetches:

Only the first two rows read the global feeds, and both live in packages/app-shell. The record- and page-scoped readers ask different questions and are untouched.

The bell renders in four layouts — HomeLayout (variant="home"), OrganizationsLayout and OrganizationLayout (variant="orgs"), ConsoleLayout (variant="app") — plus AiChatPage, which renders AppHeader variant="home"; there is no separate ai-chat variant (AppHeaderVariant = 'app' | 'home' | 'orgs'), so the AI screen is covered by the home cases.

Chosen shape: one shared fetch, module-scoped store

Un-gating alone would have fixed the emptiness by paying for it twice — on /home the bell and the cards mount in one tree, so two owners means two approvals requests and two sys_activity reads per page. That is the trade-off the card declined to settle by duplicate polling.

New packages/app-shell/src/hooks/sharedUserFeeds.ts owns each feed: one in-flight request, one 30s approvals poll, one 404-retires-the-feature rule. AppHeader and useHomeInbox both subscribe via useSyncExternalStore; neither fetches these two streams any more.

A module-scoped store rather than a context provider, because both consumers are already inside this package (no new dependency edge either way), and a store needs no provider mounted above every call site — the one-fetch guarantee holds no matter which of the four layouts renders the bell. The dedupe is structural, not agreed: there is no second producer left that could drift, so the badge and the card cannot show different numbers.

The dedupe has two layers: inFlight, set synchronously before the first await, collapses two consumers attaching in the same commit; a 30s freshness window covers the later mount (the header commits a beat before the page body). useHomeInbox keeps its narrower cut of the rows — human actors only, sys_*/ai_* churn dropped — by filtering the shared feed at its own call site instead of issuing its own query.

Its sys_inbox_message read is deliberately left alone: Home asks a different question there (top-limit titles, no read-state receipts) than the bell does (top-20 joined with sys_notification_receipt for unread state). That duplicate predates this card — filed separately as #4225.

InboxPopover.tsx needed no change; it already takes pendingApprovalsCount and activities as props, and every empty state it rendered was truthful about the data it was handed.

Presence boundary

isApp keeps the meaning it was introduced for. Measured boundary: presence was never a read at all. useTenantPresence is a transport-level subscription (PresenceProvider.subscribeTenant), and the effect formerly named fetchPresenceAndActivities explicitly never probed it — its one and only read was sys_activity. So the split is not "share the fetch, keep the presence fetch gated"; there is no presence fetch. The boundary is a render gate, and it stays exactly where it was:

• ConnectionStatus renders only under isApp && connectionState
• PresenceAvatars renders only under isApp && activeUsers.length > 0

Three cases pin it: no avatars and no connection dot off-app, both present inside an app, and no read in any variant names presence. The dividing line is data scope, not surface — user- and tenant-scoped feeds follow the bell wherever it renders; app-shell chrome does not.

Evidence

Reverse verification, git checkout origin/main -- AppHeader.tsx useHomeInbox.ts, same test file — direction predicted before running:

Tests  10 failed | 12 passed (22)      ← fix removed
Tests  22 passed (22)                  ← fix restored

The 10 reds are the six home/orgs Approvals/Activity/badge cases, the empty-approvals case, and the three shared-fetch cases. The 12 greens are controls that must not move: the three variant="app" cases, the three presence-boundary cases, and #4110's six.

Two directions worth stating plainly, because the obvious reading of each is wrong:

• The shared-fetch cases do not go red on their read-count assertion. On main, Home issues exactly one approvals read and one sys_activity read — useHomeInbox alone, the bell being gated — so toHaveLength(1) passes there. They fail earlier, on the divergence itself: Expected "2 pending approvals", Received "0 pending approvals" while the card next to it reads 2. Those assertions are a forward pin against a future naive un-gating, not evidence about this bug.
• The presence cases are green on both sides, by design. A boundary pin's job is to show nothing moved. The first draft anchored its settle point on the sys_activity read, which the home variant does not issue on main — so it went red for a timeout that says nothing about presence. Re-anchored on the inbox read (ungated in every variant since fix(app-shell): the bell polls the inbox on every console surface, not only inside an app (#4110) #4199), it is now green before and after, which is what makes it a control. That is the second commit.

Local gates, re-run after merging current main (which brings the @objectstack/spec rc.6 bump):

pnpm --filter '@object-ui/app-shell^...' build          → Done (closure first)
vitest run packages/app-shell/                          → 331 files, 3111 passed | 1 skipped, 0 failed
vitest run .../AppHeader.inboxVariant.test.tsx          → 22 passed (22)
pnpm --filter '...@object-ui/app-shell' type-check      → app-shell + console + 2 examples, all Done
eslint packages/app-shell                               → 0 errors (sharedUserFeeds.ts: 0 problems)
node scripts/check-control-bytes.mjs                    → OK (3924 tracked files)

The downstream sweep uses the prefix filter (...@object-ui/app-shell) — the four packages that depend on app-shell, not its dependencies. It needed pnpm --filter '@object-ui/console^...' build first; without it the failures were Cannot find module '@object-ui/plugin-map' and friends, i.e. unbuilt siblings outside app-shell's own closure, not this change.

CI status — three red jobs, none of them this PR's

Lint green. Type Check red. Test shards 2 and 3 red. Every one of those failures is main's, inherited via the rc.6 spec bump (#4169 / tracker #4167), and none is in a package this PR touches:

Three independent lines of evidence:

1. main is red on its own. The Type Check job failed at Verify spec-named symbols are derived, not hand-written on 38ab5054f and on a9a67ec5b — the latter being this PR's original base.
2. Removing this PR's diff changes nothing. Reverting the three source files to main and deleting sharedUserFeeds.ts, then re-running the same tests on the identical tree: Tests 6 failed | 60 passed (66) — byte-identical to the run with the diff in. Same for the tsconfig.typetests.json errors.
3. Merging current main changed nothing. The failure set before and after the merge commit is the same, so it does not track this branch's staleness either.

Measured detail added to the tracker: #4167 (comment). One surface there was previously unrecorded — packages/app-shell/src/utils/resolveActionParams.test.ts fails only under tsc -p tsconfig.typetests.json, while tsc --noEmit is clean, so a check that stops at the first command reads green.

Changeset: .changeset/bell-approvals-activity-off-app-4197.md, @object-ui/app-shell patch.

Out of scope

sys_inbox_message is still read twice on Home — once by the bell's 10s poll (top-20 + receipts, for unread state) and once by useHomeInbox (top-limit titles). It predates this card: #4199 un-gated the bell's inbox poll without merging it into Home's. It is mergeable — Home's rows are a prefix of the bell's superset — but the queries differ in shape and the merge is its own change. Filed as #4225 (finding, unassigned).

The rc.6 fallout above is tracked on #4167, where the three surfaces its checklist did not yet enumerate are now recorded.

Generated by Claude Code